Virtual environment manager for network computers

ABSTRACT

A system and method for a downladable just-in-time middleware called VEM that provides access to network services, including system services such as printing and local storage, to applications that run on Network Computers. The VEM configures the default client services and stores information about these services. When an application executing on the Network Computer wishes to use one of the services, it communicates with its local VEM. The VEM returns a hanlde to the appropriate service to complete the service request.

I. BACKGROUND OF THE INVENTION

a. Field of the Invention

This invention relates to network computing. More specifically, thisinvention relates to methods and means for providing access to networkservices (for example, system services such as printing and localstorage) to applications executing on network connected computers.

b. Related Art

As the network computing paradigm becomes ubiquitous, simplifiedinexpensive desktop computers, known as the Network Computers, that haveno means of independent existence will become common place. Such devicesmay run a low function operating system (for simplicity) and rely onservers for basic system services including local storage, printing, andmonitoring. While traditional clients, such as PCs, provide their ownbasic system services they are also likely to seek additional servicesfrom the network.

Existing approaches used to provide these basic system services toapplications include the existence of a full-feature operatingenvironment on the Network Computer and/or the requirment that eachapplication provide its own set of needed services. The former approachis not feasible for network clients because these computers are notnecessarily equipped with adequate physical resources such as physicalmemory and attached peripheral devices (e.g., disk drives) to support afull-feature operating environment (e.g., in the case of a NetworkComputer). The latter approach has the drawback of making eachapplication aware of the platform and environment it can be run under sothat it can provide support for necessary basic system services.Further, the former approach adds to the cost of the network clients,while the latter approach adds to the complexity in the design ofapplications.

II. SUMMARY OF THE INVENTION

It is an object of the present invention to provide a flexible,powerful, and portable means for enabling network based services forclients.

In a preferred embodiment, a downloadable middleware called the VirtualEnvironment Manager (VEM) is provided. The VEM allows applications to bedeveloped completely independently of the architecture and environmentof a client computer and the servers it connects to. For a client (i.e.,a network computer) to access a service, the VEM queries a ServiceDirectory Table available on one or more connected servers. The accessto the Service Directory Table returns a handle, which is used toconnect to the indicated service provider.

III. BRIEF DESCRIPTION OF THE DRAWING

The present invention will be understood by reference to the drawing,wherein:

FIG. 1 depicts a loosely coupled system suitable for use with thepresent invention;

FIG. 2 show the flow chart for the boot phase of the network computer;

FIG. 3 shows the flow chart for initial steps taken by each serviceprovider;

FIG. 4 shows an instance of the system state with the VEM configured;

FIG. 5 shows the flow control process for an application when it wishesto use a network service; and,

FIG. 6 shows an example desktop.

IV. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

A loosely coupled system suitable for use with the present invention isillustrated in FIG. 1. The system includes several computers 102-106interconnected by way of a communication network 112. Of thesecomputers, some are known as Network Computers 106(1), 106(2), becausethey rely on services available via the network to provide many of theirbasic functions. Others are known as service providers 104(1), 104(2),104(3) because they provide network services, such as basic systemservices, to the Network Computers. Some of the computers are also knownas Service Directory Managers (SDMs) 102, because they maintain a listof services that are provided to network computers by the serviceproviders.

The Network Computers 106 can be embodied, for example, on a JAVAterminal, a personal digital assistant (PDA) or an internet terminal.The communication protocol is HTTP and TCP/IP. The network 112 can be,for example, a token ring. The service systems 102, 104(1), 104(2),104(3) can be embodied, for example, on IBM RISC System/6000 machinesusing AIX 4.2.

A logical organization can be placed on the physical system desrcibedabove. This organization can be described by a three tier client/serverstrategy. In this strategy, tier 1 represents the client function, tier2 represents the service provider and tier 3 represents the data objectserver (i.e., information storage). The system described in the presentembodiment relates to tiers 1 and 2 and the interface in between. Theinterface in between tiers 2 and 3 is unrestricted, so users can rely onconventional, tried and true data information access systems. Note thata service provider can be designed to either reside completely on a tier2 server or to allocate its function between tiers 1 and 2 by providinga special service stub.

Each Network Computer includes a Virtual Environment Manager (VEM)108(1), 108(2) that is downloaded from a Service Provider by way of thecommunication network 112. The VEM is embodied as program codeinstantiated in the random access memory (not shown) of the NetworkComputer. In particular, the VEM provides a base class called VEMCLASS(defined in Appendix A) that it relies on for defining a collection ofobjects (in the sense of “object oriented programming”). One of theobjects included in each VEM is an active entity called the VirtualEnvironment Superviser (VES) 109(1), 109(2) that is responsible formaintaining the VEM state. In a preferred embodiment, the VES is anactive JAVA object and is directly instantiated from the VEMCLASS. TheVEM state includes a table of configured services 110(1), 110(2) and atable of active applications 112(2), 112(2). Both the table ofconfigured services and the table of active applications are alsoinstantiated in the random access memory of each Network Computer.Applications inherit from the VEMCLASS in order to interact with theVES. The object class is compiled with the application and bound to thename space of the application.

According to an embodiment of the present invention, when a networkcomputer is switched on, it goes through a boot process in which itreadies itself for use. At the end of the boot process, the networkcomputer prompts the user for identification. The identification processcan be, for example, typing in the user name and a password. After useridentity verification, the network computer presents the user with adesktop environment.

The desktop environment is preferably a JAVA container. The JAVAcontainer runs on top of a JAVA virtual machine. Both the container andthe JAVA virtual machine are provided by a program such as a Web Browser114(1), 114(2) (e.g. Netscape Navigator) which executes on the NetworkComputer. The browser can be downloaded during the Network Computer'sboot sequence or provided as an integral part of the Network Computer.

As part of the initialization process, the browser downloads the VES anda configuration file for the user from a Service Provider. The VES usesthe configuration file to set up the user's desktop environment(desktop). An example desktop (which can be in the form of a home page)is shown in FIG. 6. The configuration file contains a list of system andapplication services that the user accesses most frequently. Thesesystem and application services can be embodied as icons 602 or buttons604 and/or a textual list 606 displayed on the desktop. The system andapplication services can be accessed as hyperlinks or as direct controlbuttons where the appropriate JAVA code has been downloaded. Theremainder of the VEM is downloaded with user applications.

The initial logging and download of the home page is described in FIG.2. In step 202 the Network Computer is powered on or reset by a user. Inresponse, in step 204 the Network Computer commences its machinespecific, conventional boot sequence. This sequence can be extended toinclude downloading of the Web browser. In step 206, the NetworkComputer prompts the user for a username and password. The NetworkComputer uses conventional methods to determine if the username andpassword are valid in step 208. Those of skill in the art will recognizethat steps 206 and 208 could alternatively be performed as part of step204. If step 208 determines that either the username or password are notvalid, the method returns to step 206. If the username and password arevalid, in step 210 the Network Computer downloads the VES and theconfiguration file.

When a VES is downloaded for a user, it initiates configuration of allservices that are in the configuration file. The configuration file canbe of a conventional flat file format. For example, the configurationfile can be in the form of a Bookmarks file of the type used by NetscapeNavigator 3.0. This configuration is performed by contacting theappropriate service providers and initializing the client's table ofservices 110 with the server information. Stubs are also downloaded forthose services that reside on both tiers 1 and 2.

In addition to the currently configured services, the VES has access toall services available on the network. This enables a user to add anyavailable service to the desktop and as a result to the user'sconfiguration file.

Service access is provided by a Service Directory Manager (SDM) thatmaintains a table of services referred to as the Service Directory Table(SDT) 114 (shown in FIG. 1). The Service Directory Table containsinformation about system and application services offered by the ServiceProviders on the network. It should be understood that there can be aplurality of SDMs on the network, each maintaining a SDT or accessing asingle instance of the SDT.

When a Service Provider is connected to the network, it announces theset of services it offers to the SDM. The steps taken by each ServiceProvider in announcing the set of services it offers are shown in FIG.3. In step 302 the Service Provider generates a list of services that itoffers. In step 304, the Service Provider identifies the SDM that isresponsible for maintaining the list of services in the network. In step306 the Service Provider scans the list of services and determines thenext service to be registered. If there is another service to beregistered, in step 308 the Service Provider sends a REGISTER message tothe SDM (directory M) and then returns to step 306. If there are no moreservices in the list, initialization is completed in step 310. It shouldbe understood that steps 306 and 308 can be replaced with a single stepin which the entire list is read only once and then sent to theappropriate SDM as part of a single message or message sequence.

An instance of the system state in which various client stubs arelocated at the Network Computers is shown in FIG. 4. The Figure showsthree Service Providers: a Print Server 402, a Fax Server 404 and a MailServer 406. The SDT 408 includes information about the three serviceproviders. In particular, the information describes the type (attribute)of service and the location of the Service Provider which provides theparticular service. The particular instance of the Network Computer 410includes various applications 412 (AP1-APn), an active VES object 414which contains a table of configured services and passive stub objects416 (Print Client Stub, Fax Client Stub, Mail Client Stub) that provideconnections to the services. The VEM includes the VES, the stubs and theVEMCLASS portion of each application.

The VEM will now be discussed in more detail. For reference, codedefinitions for the VEM include the VEMCLASS and the client and serverinterfaces. These are is shown in appendices A and B respectively. FIG.5 shows the flow control process for an application when it wishes touse a network service. As previously discussed, loading the VES into aclient is analogous to looking at an HTML page in a browser. The VES isdownloaded and it's init( ) method is called. The init( ) methodsynchronizes itself to ensure that the class variable VE_supervisor isinitialized only once. Any subsequent attempts to start a VES aredisabled. The VES assigns itself id=0 by setting the VEM_id instancevariable. The class variable, num_AFE, is then incremented. A registry(that contains the Configured Services Table 110 and the Table ofApplications 112) and a shared_services table are created. Finally, adirectory services remote object is instantiated, using the DS_serverparameters passed in the html file.

Once the VEM has been downloaded and initialized, applications (APs) canbe downloaded. (Note that APs are assumed to be applets in thisdiscussion. The VEM supports applications, though applets are preferredfor improved manageability.) In it's init( ) method, an AP should callthe registerAFE( ) method. This call sets the AP's instance variable,VEM_id, to the class variable num_AFE, and increments num_AFE. Sincenu_AFE is never decremented, the AP now has a unique id. The VES is thencalled to create an entry for the AP in the registry (the Table ofApplications 112). At this time, the entry contains only the appletobject reference, id and name, but it can be expanded later as needed.The registerAFE( ) method returns a unique key, called a “cookie”, tothe AP to ensure that access to the AP information in the registry iscontrolled. The AP is now fully integrated into the VEM environment andis now capable of VEM function.

When the AP needs a service, it first requests the VEM to register theservice using one of the registerService( ) methods. On serviceregistration the VES checks the directory service (the SDM) using theLookupService( ) method to get the handle to the service and to see ifthe service has a stub. If it does, the stub is downloaded. The VEM thenadds a service entry to the registry (the Configured Services Table 112)that includes the service's handle and, if appropriate, a reference tothe stub. A cookie is passed back to the AP. Once the service is in theregistry, both the AP and the VES can access it as needed.

The choice of which registerservice( ) method is called depends on: (1)whether a generic service is needed (i.e. one identifiable with just aname), or whether a more custom service is needed (e.g. one that isidentified with a list of attributes as well as a name); and (2) whetherthe service shared. If the service is not shared, then the APregistering the service is the only one that gets access to the cookie.Otherwise, if the service is present, a cookie is passed back that isthe same as those given to other APs for the service. If a sharedservice is not yet available in the VEM, the shared_service variable isupdated to reflect the availability of a new, shared service, and a newcookie is passed back to the AP.

Access to shared services can be controlled using an access controllist. Alternatively, shared services can be globally available, i.e. anyAP can receive the cookie for the service just by asking for theservice. Shared services are useful for minimizing the number, of serverstubs resident on a client. They can also be useful if service behaviorchanges caused by one AP are used by another interactively.

Shared services can be removed from the VEM in various ways. Accordingto a first embodiment, a reference count is kept for each service. Thereference indicates how many APs currently have access to the service.When the reference count reaches zero, the service is removed by theVES. According to an alternative embodiment, only the AP that originallybrought in the service is allowed to remove it.

Once the VEM state has been updated to include the service, the AP canget the handle by issuing the getServiceHandle( ) method, or get thestub by using the getServiceInstance( ) method. The AP is then free tomake a connection of any sort and use the service. The VEM can beembodied to restrict how an AP and service communicate. When the serviceis no longer needed, the AP calls the RevokeService( ) method thatupdates the VEM state as follows: if the service is unique to the APthen the service is removed; if the service is a shared service then itis removed in accordance with the rules discussed above.

Now that the invention has been described by way of the preferredembodiment, various modifications and improvements will occur to thoseof skill in the art. Thus, it should be understood that the preferredembodiment has been provided as an example and not as a limitation. Thescope of the invention is defined by the appended claims.

1-18. (canceled)
 19. A method for providing on-demand access to andinteraction with system services to applications executing on a networkcomputer, comprising the steps of: a) in response to a demand from auser, downloading executable code comprising a virtual environmentmanager for providing access to remote network system and applicationservices; b) identifying a set of system and application services; c)configuring the set of system and application services by contacting aplurality of appropriate remote service providers for each particularone of the system and application services and downloading one of clientstubs and a handle for each one of the service providers; d) maintaininga list of configured services; and e) providing access to the configuredservices.
 20. The method of claim 19 comprising the further step ofsharing access to the system services by a plurality of theapplications.